Method and system for event management in business processes

ABSTRACT

An event management method for a computer implemented business process system. The method includes the step of executing a plurality of events for representing a business process, the business process implemented by progressing through the events. A plurality of event nodes are executed for the business process, the event nodes defining points in the progress of the business process for communicating with an external process to exchange information. The business process is executed by sequentially executing the events, wherein the execution proceeds in accordance with the event nodes.

TECHNICAL FIELD

[0001] The present invention relates generally to electronic commerceinformation technology. More specifically, the present inventionpertains to an electronic commerce information management system fordelivering business data and services.

BACKGROUND ART

[0002] The use of the Internet for electronic commerce and forinformation retrieval has rapidly proliferated in today's modern world.Hundreds of Internet sites and Web portals are constantly accessed bymillions of users for obtaining information, news, entertainment, andthe like, via the World Wide Web. Many aspects of everyday life arebecoming electronically information based, and the access, control, andthe use of such electronic information, through the use of various typesof electronic devices, is never far from hand. For example, a desktopcomputer allows access to banking functions (e.g., checking, billpaying, etc.), shopping (e.g., groceries, clothing, etc.), the weather,and virtually any other need of an individual.

[0003] As described above, the emergence of the Internet is changingmany aspects of modern life. However, no area is undergoing as rapid andsignificant changes as the manner in which businesses operate. Today,large and small companies are using the Web to communicate with theirpartners, to connect with their back-end systems, and to performelectronic commerce transactions. Users will soon witness the evolutionof today's e-business and e-commerce into e-services. Examples ofe-services are stock trading, customized newspapers, real-time trafficreport, or itinerary planning.

[0004] The e-service environment creates the business opportunity forproviding value-added services, which are delivered by composingexisting e-services, possibly offered by different providers. Forinstance, an “eMove” composite service could support customers forrelocations, by composing truck rental, furniture shipments, addresschange, and airline reservation services in a flexible way to meetvarious needs for each relocation transaction. Hence, the Web is rapidlybecoming the platform through which many companies deliver e-services tobusinesses and individual customers. E-Services are typically deliveredin their primitive forms, called basic services.

[0005] Prior art traditional approaches to service composition allow thedefinition of a composite service as a business process, specified by agraph of nodes (corresponding to activities or services to be executed).In such models, new services are started as other services complete,according to the control flow specifications. However, many processesneed to synchronize the activations of their nodes with the occurrenceof specific events. For instance, in a candidate interview process,suitable actions must be performed when the candidate decides towithdraw his/her job application: reservations for interview rooms needto be canceled, e-mails need to be sent to the members of the interviewteam, and the withdrawal need to be logged in the corporate HumanResource database. The withdrawal of a job application is asynchronouswith respect to the activities in the candidate interview process, thatis, it does not necessarily occur in correspondence to the completion ofa process activity, but can instead occur at any time during processexecution. To specify this kind of behaviors, a composition model shouldprovide primitives that enable the definition of paths in the processthat are activated as a given event occurs.

[0006] In addition, events can also provide for dynamic data exchangebetween composite services and external applications. For instance,consider a car rental process. This process needs to manage situationsin which an accident occurs to the rented car. If the process model andsystem can manage events, then the process designer can specify suitableactions to be taken as a car accident event is detected. In addition,this event may carry some parameters, such as the car license platenumber or the time needed for repair. These data can be made accessibleto the process instance in order to react appropriately to thesituation.

[0007] Depending on the type of events supported by the process model,the specifications of many other behaviors become possible: forinstance, events could be used to synchronize the execution ofactivities executed in two (or more) different process instances, tosuspend the execution of a process until a given date and time, todefine processes whose instances are created periodically or as a givenevent occurs, to detect and react to manipulations of a given processvariables, to handle exceptional situations such as the inability toinvoke a service, and many others.

[0008] There currently exists no comprehensive model or architecturethat enables the delivery of such value-added services. There exists nosolution that supports the specification, deployment, and management ofcomposite e-services, i.e., of e-services that are carried out byinvoking several other basic or composite services. There exists nosolution that provides the service developer with a simple, easy to use,yet powerful mechanism for defining services. The present inventionprovides novel solution to the above requirements.

SUMMARY OF THE INVENTION

[0009] In one embodiment, the present invention is implemented as anevent management method for a computer implemented business processmanagement system. The method includes the step of executing a pluralityof events representing aspects of a business process. The businessprocess is implemented by progressive execution through the events. Aplurality of event nodes for the business process are executed. Theevent nodes define points in the progress of the business process forcommunicating with an external process to exchange information.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated in and form apart of this specification, illustrate embodiments of the invention and,together with the description, serve to explain the principles of theinvention:

[0011]FIG. 1 shows a diagram depicting different types of events inaccordance with one embodiment of the present invention.

[0012]FIG. 2 shows a flow chart of the steps of a process in accordancewith one embodiment of the present invention.

[0013]FIG. 3 shows a diagram depicting the different types of eventnodes in accordance with one embodiment of the present invention.

[0014]FIG. 4 shows the basic architecture of a business managementprocess in accordance with one embodiment of the present invention.

[0015]FIG. 5 shows a flow chart of the runtime execution of a typicaltemporal event in accordance with one embodiment of the presentinvention.

[0016]FIG. 6 shows a broker interface architecture in accordance withone embodiment of the present invention.

[0017]FIG. 7 shows a flow chart of the steps performed by a specialpurpose application in accordance with one embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

[0018] Reference will now be made in detail to the embodiments of theinvention, examples of which are illustrated in the accompanyingdrawings. While the invention will be described in conjunction with theembodiments described below, it will be understood that they are notintended to limit the invention to these embodiments. On the contrary,the invention is intended to cover alternatives, modifications andequivalents, which may be included within the spirit and scope of theinvention as defined by the appended claims. Furthermore, in thefollowing detailed description of embodiments of the present invention,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. However, it will be obvious toone of ordinary skill in the art that the present invention may bepracticed without these specific details. In other instances, well knownmethods, procedures,. components, and circuits have not been describedin detail as not to unnecessarily obscure aspects of the presentinvention.

[0019] Embodiments of the present invention provide a comprehensivemodel and architecture that enables the delivery of value-addedE-business services by extending traditional composition model with arich and flexible event model. Embodiments of the present inventionprovide a solution that supports the specification, deployment, andmanagement of composite e-services, i.e., of e-services that are carriedout by invoking several other basic or composite services. Embodimentsof the present invention is a solution that provides the servicedeveloper with a simple, easy to use, yet powerful mechanism fordefining services by composing basic ones.

[0020] For example, in one embodiment, an event management method for acomputer implemented business process system is implemented. The methodincludes the step of providing a plurality of events (and other steps)for representing many aspects of a business process, the businessprocess implemented by progressing through the events sequentially, inparallel, or conditionally. A plurality of event nodes are provided forthe business process, the event nodes defining points in the progress ofthe business process for communicating with an external process toexchange information or to synchronize the execution. The businessprocess is executed by executing its steps, which may include eventnodes. Events can be classified into state change events, error events,application events, and temporal events. The event nodes can be requestnodes and publish nodes. The computer implemented process and evendefinition can be XML (extensible markup language) based.

[0021]FIG. 1 shows a diagram depicting different types of events inaccordance with one embodiment of the present invention. Embodiments ofthe business management process provides advantages by, for example,defining a set of event classes, or types, that are of interest in thecontext of business process management. As depicted in FIG. 1, a set ofevent types 100 can be further subdivided into more specific types ofevents. For example, as will be described in greater detail below,events can be classified into: state change events 111, error events112, application events 113, and temporal events 114. For each of themultiple event types 100, parameters are identified that events of thatclass should have, when events are raised, and by whom. The embodimentsof the present invention are also compatible with an XML-based syntax tospecify the behavior of publish and request event nodes. Additionally,embodiments of the present invention implement a notion of temporalevents 114, wherein temporal events can be handled in the same fashionas other types of events, thereby simplifying event management inbusiness processes. Symbolic dates are a specific type of temporal event114. Symbolic dates are implemented for such artificial dates such as“Pay-Day”, or “Easter”, or “Thanksgiving” etc.

[0022] Referring still to FIG. 1, embodiments of the present inventionutilize the multiple event types 100 to enable the delivery ofvalue-added services by, for example, implementing a model andarchitecture that supports the specification, deployment, and managementof composite e-services, i.e., of e-services that are carried out byinvoking several other basic or composite services. The event managementfunctionality of the embodiments utilize the multiple event types 100 toprovide the service developer with a simple, easy to use, yet powerfulmechanism that extends traditional mechanisms for defining services bycomposing basic ones.

[0023] Embodiments of the present invention allows the definition of acomposite service as a business process, specified by a graph of nodes(corresponding to activities or services to be executed) which linktogether a series of, for example, state change events 111, error events112, application specific events 113, and temporal events 114. In suchmodels, new services are started as other services complete, accordingto the control flow specifications. Additionally, embodiments of thepresent invention provide for the synchronization of the activation ofmultiple processes and their respective nodes with the occurrence ofspecific events.

[0024] Referring still to FIG. 1, in the embodiments of the inventiondescribed below, the different types of events 100 relevant in thecontext of service composition, and the approach to event management isdescribed. Classes of events 100 are defined with respect to the mannerin which they are handled by embodiments of the invention, andcharacteristics of events in each class (e.g., classes 111-114) aredescribed. One objective of the embodiments of the event model andlanguage has been that of making the specifications of the event to besent or received as simple as possible. Preferably, events 100,regardless of their type, are specified in a uniform fashion, using thesame formalism and the same underlying basic concepts, so that theprocess designer does not need to learn different languages to specifydifferent kinds of events. High-level constructs can be provided,especially in the critical area of time management, to further simplifyevent handling.

[0025] In accordance with embodiments of the present invention, acomposite service refers to a workflow process that composes other basicor composite services. A process can be modeled by a graph (e.g., FIG.2), which defines the order of execution among the nodes in the process.The graph may include service, decision, and event nodes. Service nodesrepresent the invocation of a basic or composite service, decision nodesspecify the alternatives and rules controlling the execution flow, whileevent nodes enable service processes to send and receive several typesof events.

[0026] A process instance is an enactment of a process definition. Thesame process may be instantiated several times, and several instancesmay be concurrently running. Service nodes can access and modify dataincluded in process variables. Each process instance preferably has alocal copy of these variables, and embodiments of the present inventioncontrols access to these data.

[0027] Different types of events 100 in accordance with embodiments thepresent invention are now described. Embodiments of the presentinvention can capture and manage several different types of events. Someof them are used for exception handling purposes, some for time-basedsynchronization of service execution, other for synchronization anddynamic data exchange with other services, and other again to monitorservice state changes and react appropriately. Preferably, events cancarry parameters. Different types of events have different parameters(although a few parameters are common across all event types).

[0028] One type of event is a state change event 111. State changeevents 111 are raised by changes in the process instance state. Thisincludes the execution state of nodes and process instances as well asthe value of process variables. For instance, in a bank accountmanagement process, actions may need to be taken when the value ofprocess variable balance goes below a threshold. Events of interest canbe restricted to a specific node, process instance, or processdefinition, or they can be unrestricted (capturing every state change).

[0029] It should be noted that the term “process”, “workflow”, and“composite service” are used synonymously. Additionally, it should benoted that an instance of a process refers to the execution of aprocess.

[0030] State-change events 111 preferably have the following parameters:

[0031] Event type: every type of event has an event type parameter. Forall state change events, its value is set to “state_change”.

[0032] Variable name: the name of the variable that changed value or, ifthe event is related to a node state change, the name of the node thatchanged state.

[0033] Old value: the value of the variable prior to the modification(or the state of the node prior to the change)

[0034] New value: the value of the variable after the modification, orthe new state of the node

[0035] Process definition id: the identifier of the process definitionto which the modified process instance belongs to.

[0036] Process instance Id: the identifier of the process instance inwhich the state change occurred

[0037] Occurrence time: the date and time of the event occurrence.

[0038] Error events 112 are notifications of run-time errors occurredduring process execution, such as when no service can be selected toexecute a node. As for the previous type, events of interest can berestricted to those caused by a specific node, process instance, orprocess definition, or they can be unrestricted.

[0039] Preferably, error events 112 have the following parameters:

[0040] Event type: For all error-handling events, its value is set to“error”.

[0041] Node name: the name of the node to which the error event isrelated. If the error is related to a process instance rather than to anode, this parameter has a NULL value.

[0042] Process definition id: the identifier of the process definitionto which the affected node or process instance belongs.

[0043] Process instance Id: the identifier of the process instance towhich the event is related

[0044] Error type: a string defining the type of error notified by thisevent.

[0045] Occurrence time: the date and time of the event occurrence.

[0046] Application-specific events 113 do not have a predefinedsemantics; they are qualified by their name, may carry severalparameters, and are explicitly notified to the process engine by anotherprocess or by external parties. For instance, the customer Cancel eventin a travel reservation process might represent the situation in whichthe customer cancels his/her travel reservation. The candidatewithdrawal event introduced above is also an example ofapplication-specific event.

[0047] Application-specific events 113 may carry an arbitrary number ofparameters. The only event parameters common to all application-specificevents 113 (besides the name) are the occurrence time and the eventtype, with the same semantics as above.

[0048] Temporal events 114 are raised at specified points in time.Embodiments of the present invention can detect and raise three types oftemporal events 114:

[0049] Instant: the event is raised only once, at a specified date andtime.

[0050] Usually, the date and time are specified by providing the time ofthe day, plus the day, month, and year. Embodiments of the presentinvention also allows the definition of symbolic dates such asChristmas, Easter, or Thanksgiving, as discussed below.

[0051] Periodic: these events are raised periodically. The periodicevent language allows the specification of simple periodic intervals(e.g., “every 3 hours) as well as the definition of expressions thathave knowledge of the calendar, such as “every Monday at 2pm”, “every USelection day at noon”, or “on the 28th day of each month”.

[0052] Interval: interval events are raised as a given interval haselapsed since a base event (e.g., 20 minutes after the activation of thetask, or 2 days after the car accident). The base event can be an error,state-change, application-specific, temporal/instant, ortemporal/periodic event.

[0053] Preferably, all temporal events have parameters occurrence timeand event type.

[0054]FIG. 2 shows a flow chart of the steps of a process 200 inaccordance with one embodiment of the present invention. Process 200depicts the steps involved in a candidate interview process as managedby one embodiment of the present invention. Although process 200 isdescribed in the context of a candidate interview process, it should benoted that a number of different types of workflows can be implementedand automated with embodiments of the event management process of thepresent invention.

[0055] Referring still to FIG. 2, the steps 201-215 describe a candidateinterview process. As depicted in FIG. 2, lozenges represent servicenodes (e.g., steps 101, 103, 107, 108,109,110, 112, and 113), circleswith incoming/outgoing arrows represent event nodes (e.g., step 111 andstep 114), while the other symbols represent decision nodes.

[0056] Process 200 begins in step 201, as when a new instance of theprocess 200 is invoked by a candidate applying for employment. In step201, service Get Interview data is invoked to collect informationregarding the candidate, the interview team, and a set of possibleinterview dates. Then, in step 202, if the candidate is a foreigner,process 200 proceeds to step 203, where a lawyer analyzes his/herimmigration status to determine whether the candidate can work in the US(or is likely to be able to get a visa) or not. If not, the hiringmanager is informed and the process 200 terminates. Otherwise, process200 proceeds to step 204 and 207, where an administrative assistantdefines the interview schedule, according to the schedule andavailability of the interview team members. After the schedule has beenfixed, three services are invoked in parallel: “Book rooms” (e.g., step208) will book conference rooms according to the schedule provided.“Send info to interview team” (e.g., step 209) will send the candidate'scurriculum information to the team members. Finally, “Arrange candidatetrip” (e.g., step 210) is executed by a company travel agent and willtake care of verifying the candidate's need in terms of travel tickets,hotels, and car, for a three-day period centered on the interview day.

[0057] Referring still to FIG. 2, after steps 208-210, no action needsto be taken until the interview date. In step 211, this is modeled bythe event node “wait interview date”, that will let the flow of process200 proceed only at the specified interview day. The event node in step211 is followed by the parallel activation of several services in step212 (one for each member of the interview team), that will collectfeedback from every interview team member. The parallel activation ofseveral instances of the same service of step 212 is modeled in thepresent embodiment by a Multiservice node. Finally, in step 213, as allinputs have been gathered, the hiring manager makes the final decision.An event node in step 214 notifies the final decision to all otherinterested processes and/or services, that will take care of performingthe appropriate actions (e.g., start the hiring process or notify thecandidate about the rejection). Process 200 subsequently ends in step215.

[0058] Thus, in the Candidate Interview example of process 200 above,multiple event types (e.g., as shown in FIG. 1) are used to synchronizethe execution of the multi-service interview so that it starts on theappropriate date and to publish the result to any interested party.Achieving these (and many other) behaviors without an integrated eventmanagement process would be unduly hard and time-consuming.

[0059] Referring now to FIG. 3, a diagram depicting the different typesof event nodes 300 in accordance with one embodiment of the presentinvention is shown. The description of FIG. 3 below describes the mannerin which composite services can publish or receive events. In theembodiments of the present invention, points in process execution whereevents should be sent or received are specified by means of event nodes,e.g., event nodes 300. There are preferably two types of event nodes:Publish nodes 301 and Request nodes 302. Publish nodes 301 raise anevent, which can be notified to other process instances or to other,external parties. Publish nodes 301 are non-blocking: as the event isnotified, process execution proceeds immediately by activating thesubsequent node.

[0060] As shown in FIG. 3, request nodes 302 correspond instead torequests of events. Request nodes 302 are blocking: as a request node302 is reached in the control flow of a given process instance, the flow(along the path where the request node 302 is defined) stops until anevent with the specified characteristics is delivered to that node.

[0061] Publish nodes 301 denote points in the flow where a processnotifies and communicates with an application-specific event. Thespecification of a publish node 301 includes the definition of the eventto be generated, described in one embodiment by an XML string. Inparticular, a set of <name,value>pairs specifies the event parameters.Values may be defined by constants or may refer to the name of a processvariable, meaning that the actual value of the parameter is set to thevalue of process variable at the time the event node is executed.

[0062] For example, the candidate interview process 200 described abovepublishes an event notifying the interview result (to be captured by allother defined services interested in this event). Assume also that theevent must indicate the name of the candidate, the evaluation result,and the interview date. In one embodiment, such a node can be specifiedas follows: <PUBLISH_NODE ID=“Intervlew_Result”> <NAME> Interview Result</NAME> <EVENT_PARAMETER> <PAR_NAME> candidate_name </PAR NAME> <VALUE>$Candidatelnfo.Name </VALUE> </EVENT_PARAMETER> <EVENT_PARAMETER><PAR_NAME> result </PAR_NAME> <VALUE> $Decision </VALUE></EVENT_PARAMETER> </PUBLISH NODE>

[0063] In the above example, event parameters “candidate_name” and“result” are set by means of process variables.

[0064] A publish node 301 can restrict the target processes or servicethat can receive the event. Possible restrictions, specified by means ofthe <RESTRICT TO>tag, include process (only other instances in the sameprocess can receive the event), group (only processes of the same groupcan receive the event), system (only process executed by the same enginecan receive the event), or all (every body, including external processexecution, can receive the event—This is the default).

[0065] Request nodes 302 denote points in a process where the executionis suspended (along the path where the event node is defined), waitingfor an event to be delivered. In one embodiment, each request node 302execution can receive at most one event. In order for a node to requestanother event, the node must be fired again. As the event is deliveredto the request node 302, process instance execution proceeds with theactivation of the node connected in output to the request node 302.Preferably, embodiments of the present invention do not require eventsto have a name. If defined, event names such as InterviewResult arehandled like any other parameter.

[0066]FIG. 4 shows the basic architecture of a business managementprocess in accordance with one embodiment of the present invention. Asshown in FIG. 4, the functionality comprising the business managementprocess of the present embodiment occurs primarily at either pre-compiletime (rule definition time 410), or engine execution (runtime 420). Atrule definition time 410, the various software-defined parameters andinformation describing a business process (e.g., business process 200 ofFIG. 2) are ordered and configured to implement the particular businessmanagement process of interest to a user. This includes, for example,reading request node definitions 411, generating one or more clientsthat wait for the occurrence or fulfillment of certain events 412, andreplacing various request nodes with service nodes 413 (e.g., forblocking conditions not applicable to the particular business managementprocess).

[0067] At runtime 420, the engine executes the software managing thebusiness process. For example, during the execution, successive nodesare executed 421. Designated request nodes are assigned to specialpurpose clients to request information (e.g., provide an input to theprocess). Depending upon the specific rules in place for the particularprocess, specific next nodes are requested and executed (request node421) and subsequent request nodes are used, for example, to obtaininformation from other parties involved in the business process. In thismanner, the rules influence the progression and result of the businessprocess.

[0068] Preferably, for each request node 422, the process designerspecifies a request rule that defines the kind of events the node isinterested in (specified by a filtering rule) and the event data thatshould be captured within process variables (specified by a capturingrule). The filtering rule is mandatory, while the capturing rule must bespecified only if the requesting process needs to capture event datainto local process variables. These components are described in greaterdetail below.

[0069] Filtering rules in accordance with the present embodiments arenow described. Different event languages may have different expressivepower in defining and capturing the events of interest among those of agiven type. For instance, consider the problem of defining theapplication-specific events that a process needs to monitor. Simpleevent languages could allow the indication of the event of interest byspecifying the event name, such as car accident. However, moresophisticated functionality is often needed. For instance, the processdesigner may need to specify interest in events related to car accidentsfor a car of a given brand or with a given plate number, not just in anycar accident. Indeed, a process instance is only interested in caraccident events related to the car that the instance is managing, not inevery car accident event. Having every process receive and manage anycar accident event would be burdensome both from a process design andfrom a system perspective. Hence, an advanced event language could allowthe use of a finer granularity in specifying the events of interest, bydefining constraints over event parameters, that is, by defining anevent filtering condition.

[0070] Preferably, the event filter may be defined in terms of constantvalues or in terms of references to process variables. For instance, theplate number of interest could be given as a constant or it can be areference to a process variable, so that each process instance canreceive a different event, and exactly the event that is relevant tothat instance.

[0071] As another example of frequently needed functionality that goesbeyond what provided by simple name-based event matching, consider thecase in which a process wants to be notified when a temporal/instantevent occurs, in which the date and time are not fixed beforehand, butcan be defined during process instance execution, and indeed can differfrom instance to instance. The timestamp could be specified as areference to a process variable (of the type timestamp) rather thanbeing a constant value: in this way the timestamp to be monitored can beset on a per-instance basis by a previously executed service node.

[0072] Referring still to FIG. 4, with request node definition (e.g.,request node definition 411), a filtering rule in a request node definesthe characteristics of the events that the node is interested inreceiving. Generally, request nodes can be defined to request error,state change, temporal, or application-specific events. Preferably, allevent types are specified using the same formalism: the event ofinterest is simply defined by a Boolean condition over event parametersand process variables. Typically, the condition compares eventparameters with constants or with the value of process variables tocheck if these values match. At runtime 420, when a request node isreached by the control flow (i.e., it is fired), process variablespresent in the filtering rule are replaced with their current value, anda request for the event of interest is issued. The embodiments of thepresent invention will deliver to the node the first event thatsatisfies the condition and that occurred after the request nodeactivation (hence, events are not cached).

[0073] Examples of filtering rules for the different event types are nowprovided.

[0074] Error events: Assume that the designer wants to specify a requestnode that captures errors related to XOR decision nodes (that is, adecision node that should activate one and only one output path),executed in the same instance, whose rule activate multiple outputpaths. This semantics can be achieved in fellow by specifying a requestnode as follows: <REQUEST_NODE D=“catch_xor_errors”> <NAME> Catch XorErrors </NAME> <FILTER event_type=“error”>error_type=“xor_multipleoutput” and process_instance_id=$proc_inst_id</FILTER> </REQUEST_NODE>

[0075] Note the constraint on the process instance parameter, whichlimits the event of interests to those occurring within the same processinstance (“$proc inst_id” is a predefined, read-only process variable,automatically maintained by the system, that contains the processinstance identifier). If we are instead interested in capturing thisevent for any instance of the “candidate interview” process, then we canspecify the following node: <REQUEST_NODE ID=“catch_xor_errors”> <NAME>Catch Xor Errors </NAME> <FILTER event_type=“error”>error_type=“xor_multiple_output” and process_definition_id=“candidate_interview” </FILTER> </REQUEST_NODE>

[0076] State change events: State change events of the presentembodiments are specified in the same fashion as error events. Thedesigner specifies the event type (event type=“state_change”) and theother parameters on which he/she wants to put constraints in definingthe event of interest. For instance, suppose that in a bank accountmanagement process, a request node monitors variable balance in order tocheck when it turns from a positive to a negative value. This node canbe specified as follows: <REQUEST_NODE ID=“catch_negative_balance”><NAME> Catch Negative Balance </NAME> <FILTER_event_type=“state_change”>variable_name=“balance” and old value >0 and new value <0 </FILTER></REQUEST_NODE>

[0077] The following node monitors instead every negative variation ofthe balance: <REQUEST_NODE ID=“catch_negative_variations”> <NAME> CatchNegative Variations </NAME> <FILTER event_type=“state_change”>variable_name=“balance” and old value < new value </FILTER></REQUEST_NODE>

[0078] Application-specific events: In this type of events, allattributes (except the event type and the occurrence time) areevent-specific. As an example of filtering rule on application-specificevents, consider the candidate interview process, and assume that theprocess designer is interested in capturing events that denote that thecandidate has withdrawn its application. We assume that this situationis described by an event whose name is Candidate Withdrawal and whoseadditional parameters are candidate_name (the name of the candidate),position (the code of the position for which he/she withdrew theapplication), and reason (the motivation for the cancellation, ifprovided).

[0079] In order to capture this event, the process designer can specifythe following filtering condition: <REQUEST_NODEID=“catch_Candidate_Withdrawal”> <NAME> Catch Candidate Withdrawal</NAME> <FILTER event_type=“application_specific”> event_name=“CandidateWithdrawal” and candidate_name=$candidateName andposition=$advertisedPosition </FILTER> </REQUEST NODE>

[0080] The above rule specifies that the event node is requesting anapplication-specific event named “Candidate Withdrawal”, in which thevalue of parameters candidate_name and position equal the value ofprocess variables candidateName and advertisedPosition at the time therequest node is activated.

[0081] Temporal events: In principle, “capturing” temporal events shouldbe different from capturing other event types. The purpose here is tospecify interest in the occurrence of a given timestamp, and there is no“event” that is actually generated and that can be captured. However, toallow the specification of events of interest in a uniform fashion, weuse a similar formalism for the specification of these events as well.In fact, the process designer may assume that, conceptually, embodimentsof the present invention often raise a temporal event every second. Thisallows temporal events to be specified by a filter on the occurrencetime parameter, by using a simple language that enables the definitionof date-time, interval, and periodic times.

[0082]FIG. 5 shows a flow chart of the runtime execution of a typicaltemporal event in accordance with one embodiment of the presentinvention. In step 501, the runtime engine executes to monitor theprogress of the business process. The runtime engine is referred to hereas the event monitor component. In step 502, the event monitor componentreceives notifications, for example, from various clients or externalprocesses, as the business process progresses. These notification arecompared against a list of alarms. Subsequently, in step 503, adetermination is made as to whether an event of this particular businessprocess has occurred. If the notifications do not indicate an eventoccurrence, steps 502 and 503 are repeated, and the incomingnotifications are continuously checked. If the one or more notificationsindicates an event has occurred, step 504 is executed, where the eventis built, wherein the event's parameters are computed. Then, in step505, depending upon the particular rules in effect, a temporal event, inthis case a notification event, is used to raise the event. This is thebasic structure applicable to each of the event types as they aremonitored by the monitor component.

[0083] Instant events: Instant events are specified by giving thetimestamp at which the event should be raised. The time can be omitted,and it preferably defaults to 00:00:00. The date can be expressed in theyyyy-mm-dd format, or it can be a symbolic date, such as Thanksgiving orChristmas. Symbolic dates are discussed below. The timestamp can also bespecified as a reference to a process variable. Preferably, only theequality operator can be used to define a constraint over the timestamp.For example, the request node Wait Interview Day of the CandidateInterview process can be specified as follows: <REQUEST_NODEID=“On_InterviewDay”> <NAME> On Interview Day </NAME> <FILTERevent_type=“temporal_instant”> timestamp=$InterviewDay 9:00:00 </FILTER></REQUEST_NODE>

[0084] Interval events: Interval events are defined by an interval and abase event. The event will be raised as the specified interval haselapsed since the specified base event. For instance, a node thatrequest the event “A week after the candidate withdrawal” is specifiedas follows: <REQUEST_NODE ID=“catch_delay”> <NAME> Catch delay </NAME><FILTER event type= “temporal_interval”> interval= 7 00:00:00 </FILTER><BASE_EVENT> <FILTER event_type=application_specific”>event_name=“candidate Withdrawal” and candidate name=$candidateName andposition=$advertisedposition </FILTER> </BASE_EVENT> </REQUEST_NODE>

[0085] The interval is preferably specified in the format dd hh:mm:ss.Intervals in terms of months and years cannot be specified, since thelength of months and years may vary, and it would therefore beundetermined. As usual, the interval may be defined by a processvariable instead of being hard-coded into the node.

[0086] Note that the request also includes the specification of the baseevent, that may include references to process variables. Hence thisrequest node is actually monitoring two events, both of which mayinclude references to process variables. To avoid ambiguities, define aclear semantics, and maintain a consistent behavior among request nodes,the value of process variables is preferably determined as the node isstarted, and the interval is computed starting from the first base eventreceived after the node is started. Subsequent events matching the baseevent filter criteria are disregarded.

[0087] Periodic events: Periodic events can be specified by providingthe base time that defines when the first of the (potentially infinite)series of periodic event should occur, and the time period that shouldelapse between two successive occurrences of the periodic event. Thetime period (preceded by keyword every) is expressed in terms of days,hours, minutes, and seconds (just like a temporal interval). Forinstance, in order to specify an event that should be raised every 20minutes, starting from 12:00am on Dec. 24, 2000, the designer definesthe following rule: <REQUEST_NODE ID=“catchperiod”> <NAME> Catch Period</NAME> <FILTER event_type=“temporalperiodic”> period=“every 20:00 from2000-12-24 00:00:00” </FILTER> </REQUEST_NODE>

[0088] Embodiments of the present invention also allow the definition ofan (optional) upper limit timestamp, preceded by keyword to in theperiod definition, that denotes a point in time from which no moreperiodic events are generated. For instance, the following expression:

period=“every 20:00 from Dec. 24, 2001 00:00:00 to Dec. 25, 200100:00:00”

[0089] specifies that the request node wants to receive a periodic eventevery 20 minutes from 12:00am on Dec. 24, 2001 to 12:00am on Dec. 25,2001.

[0090] Finally, embodiments of the present invention allow thespecification of periodic events occurring at a specific time of theday, day of the month, or day of the year. These are defined analogouslyto a timestamp, where the coarser granularities are omitted. Forinstance, a node that captures events occurring on the 27th day of themonth is specified as:

period=“on 27 00:00:00”

[0091] Again, remind that a request node can receive only one event. Tobe able to receive the next periodic event, it must be fired again (forexample, it can be inside a loop).

[0092] Capturing rules in accordance with the present embodiments arenow described. Besides defining the event of interest by means of thefiltering rule, a request node may also capture the value of eventattributes into local process variables. For this purpose, the filteringrule is coupled with a capturing rule. For instance, assume that in thecandidate interview process, the designer also wants to capture, fromCandidate Withdrawal events, the reason why the candidate canceled thejob application.

[0093] When filtering this event in the event request, an interviewprocess instance is not interested in the reason of the cancellation:events of interest are all those events that are related to the personand the position for which the process is scheduling the interview,regardless of the cancellation reason. However, when the event isreceived, the process needs to capture the cancellation reason forbookkeeping purposes (or possibly to propose higher compensations if thereason was that the candidate has received another offer).

[0094] Event parameters can be captured into process variables byspecifying a set of pairs <process variable name, event attribute name>,meaning that the specified process variable takes the value of thespecified event parameter as the event is delivered to the request node.The complete definition of a request node interested in candidatewithdrawals—including the capturing rule—is therefore as follows:<REQUEST_NODE ID=“Candldate_Withdrawal”>  <NAME> Candidate Withdrawal</NAME> <FILTER event_type=“application-specific”> event_name=“CandidateWithdrawal” and candidate_name=$candidateName andposition=$advertisedPosition </FILTER> <CAPTURE> <PAR_NAME> reason </PARNAME> <VAR_NAME> candidate_cancellation_reason </VAR NAME> </CAPTURE></REQUEST_NODE>

[0095] Symbolic dates in accordance with the present embodiments are nowdescribed. In order to simplify the specification of temporal events,the present embodiments include the concept of symbolic date. Symbolicdates are keywords that identify a specific day or time. Examples ofsymbolic dates are Thanksgiving, Christmas, or Salary-Day. When defininginstant or periodic events, process designer may use symbolic dates(prefixed by a double dollar sign) instead of actual time values. Forexample, the event “At Christmas 2001” may be defined as: <REQUEST_NODEID=“At_Christmas”> <NAME> At Christmas </NAME> <FILTERevent_type=“temporal_instant”> timestamp=2001-$$Christmas </FILTER></REQUEST_NODE>

[0096] Note that in general, symbolic dates may identify a time of theday, day of the month, or day of the year. For instance, “Christmas”specifies a day and a month. Hence, to specify a timestamp, thespecification must be completed by defining the values for the othertime granularities. Instead, the specification needs not be completed tospecify periodic events. In fact, a way to define request expressioncapturing periodic events is exactly that of specifying a timestampwithout the coarser granularities. Hence, the event “every Christmas”can be specified as: <REQUEST_NODE ID=“EveryChristmas”> <NAME>Every_Christmas <NAME> <FILTER event_type=“temporalperiodic”> period=“on $$Christmas” </FILTER> </REQUEST_NODE>

[0097] The Christmas symbolic date is simply an easier anduser-friendlier way to define a time or time period. However, the powerof symbolic dates goes beyond this syntactical rewriting. For example,assume that process designers need to model process fragments to beexecuted every Thanksgiving. The way to specify this behavior would beto define a request node that waits until Thanksgiving before firing thesubsequent nodes. Without symbolic dates, all process designers thatneed to define such a request node would have to compute the datecorresponding to the next Thanksgiving and define the node accordingly.In addition, every year the definition of the request node would have tobe updated. By using the symbolic date “Thanksgiving”, it is the systemwho takes care of computing and maintaining the correct date year afteryear.

[0098] In addition to predefined symbolic dates, users can define theirown symbolic dates. This is useful since many symbolic dates havemeaning within a given company or community. For instance, the salarypayday is typically company-specific. The definition of processfragments activated on these dates is very difficult without symbolicdates, since such dates may not have a clearly defined “formula” such asin the Thanksgiving example. On the contrary, they may vary and they mayeven be undefined at process definition time. However, by using symbolicdates, request nodes can be easily defined and maintained, since it isthe system who will take care of delivering the events when appropriate.

[0099] Users can create new symbolic dates by specifying the symbolicdate name and the timestamps in which a symbolic dates occurs.Timestamps can be specified in two ways:

[0100] 1. As a periodic event. For instance, symbolic date Christmas canbe specified as “on 12-25”.

[0101] 2. As a list of timestamps. This is the approach that would befollowed, for instance, in the salary payday example. The list can beinitially defined and later updated as the need arises.

[0102] Referring now to FIG. 6, an architecture 600 in accordance withembodiments of the present invention are now described, specifically,the architecture that integrates the above-mentioned event managementfunctionality into the composite services management. Preferably, eventnodes are implemented by reusing the main process managementfunctionality, i.e., that of selecting and invoking e-services.Composite service definition are processed by a precompiler 601 thatreplaces publish and request nodes with ordinary service nodes, assignedfor execution to a specific service, called a Broker Interface (BI) 603.The generated service nodes will include all the parameters necessary tothe BI 603 to process the event publication or request. In particular,the BI 603 will receive the XML string defining the node as well as thevalue of all process variables included in it, needed in order toappropriately filter or publish the event.

[0103] Event dispatching is managed by a message broker 604. There are anumber of message brokers available on the market that providepublish-subscribe functionality (e.g., WebMethods Enterprise, STC eGate,or BEA eLink) required by embodiments of the present invention. Hence,existing messaging platforms can optionally be used.

[0104] The BI 603 acts as the link between the management engine 602 andthe message broker 604. When a publish node is scheduled by themanagement engine 602, management engine 602 realizes that it has toinvoke the BI 603 (as specified in the service node definition generatedby the precompiler), thereby providing the XML definition of the publishnode and the specified process variables as parameters. The BI 603 thenprepares (from the XML definition of the publish node and from thereceived process variables) the actual event to be published, connectsto the message broker, and publishes the event.

[0105] Referring still to FIG. 6, event requests are instead processedby subscribing to the event of interest with the message broker. When arequest node is scheduled by the engine 602, engine 602 invokes the BI603, providing it with the definition of the request node (and inparticular of the filtering expression). The BI 603 then subscribes withthe message broker 604 for events that satisfy the filter. When such anevent is published by the broker 604 (either generated by managementengine 602 or by other applications 605) the BI 603 extracts theparameters of interest as specified in the capturing rule and returnsthem to the process engine 602, that in turn updates the processvariables of the requesting process instance.

[0106] One difference for this scheme comprises requests for temporalevents. The problem is that these events are not generated by the engine602 or by other applications 605. Hence, besides subscribing to theevent (just like for any other event request), the BI 603 also takescare of generating the event when appropriate. The BI 603 computes, fromthe request node definition, the timestamp at which the request nodewants to be notified. Then it sets up an alarm. When the alarm expires,it publishes an event with the timestamp, so that it will be received(due to the previous subscription) and delivered to the requesting node.

[0107]FIG. 7 shows a flow chart of the steps performed by a specialpurpose application in accordance with one embodiment of the presentinvention. As described above, events generated by certain specialpurpose applications (e.g., other applications 605) cause the BI 603 toextract the parameters of interest and update the process variables ofthe requesting process instance. The special purpose applicationsubscribes to the BI 603 to obtain these updates. FIG. 7 describes thisprocess.

[0108] In step 701, a special purpose application is executed. Thisapplication can be configured to accomplish a specialized function, forexample, some function not usually encountered during a managementprocess execution (e.g., notifying security, etc.). In step 702, thespecial purpose application receives a node from the runtime engine(e.g., the engine 602 from FIG. 6). In step 703, the application readsthe rules defined in the node. Subsequently, in step 704, the specialpurpose application subscribes for the event with the message broker604.

[0109] Thus, embodiments of the present invention are directed towards amethod and system for offloading execution and resources for resourceconstrained network devices. Embodiments of the present inventionprovide a comprehensive model and architecture that enables the deliveryof value-added E-business services, by extending service compositionmodels with a rich, flexible, and easy to use event mechanism.Embodiments of the present invention provide a solution that supportsthe specification, deployment, and management of composite e-services,i.e., of e-services that are carried out by invoking several other basicor composite services. Embodiments of the present invention provide asolution that provides the service developer with a simple, easy to use,yet powerful mechanism for defining services by composing basic ones.Additionally, embodiments of the present invention provide a solutionthat supports the dynamic modification of service definitions while theyare under operation, as required for businesses to be operated indynamic environments such as that of Internet-based e-servicecommunities.

[0110] The foregoing descriptions of specific embodiments of the presentinvention have been presented for purposes of illustration anddescription. They are not intended to be exhaustive or to limit theinvention to the precise forms disclosed, and obviously manymodifications and variations are possible in light of the aboveteaching. The embodiments were chosen and described in order best toexplain the principles of the invention and its practical application,thereby to enable others skilled in the art best to utilize theinvention and various embodiments with various modifications as aresuited to the particular use contemplated. It is intended that the scopeof the invention be defined by the Claims appended hereto and theirequivalents.

What is claimed is:
 1. An event management method for a computerimplemented business process management system, the method comprising:executing a plurality of events for representing aspects of a businessprocess, the business process implemented by progressive executionthrough the events; and executing a plurality of event nodes for thebusiness process, the event nodes defining points in a progress of thebusiness process for communicating with an external process to exchangeinformation.
 2. The method of claim 1 wherein events are grouped indifferent classes to simplify the specification of the events.
 3. Themethod of claim 1 further including the step of defining at least one ofthe events to include a symbolic date.
 4. The method of claim 1 whereinat least one of the event nodes is a publish node for raising an eventfor notification to the external process.
 5. The method of claim 1wherein at least one of the event nodes is a request node for requestinginformation from at least one of the plurality of events or forsynchronizing execution with at least one of the plurality of events. 6.The method of claim 5 wherein the request node is a blocking node forblocking the execution of the business process until the requestedinformation is provided.
 7. The method of claim 5 wherein the requestnode is a symbolic date request node having a non-fixed calendar date ofoccurrence.
 8. The method of claim 1 wherein the event nodes arespecified using an XML syntax.
 9. A computer readable media for use witha digital computer system, the computer readable media having computerreadable instructions stored thereon which when executed by the computersystem cause the computer system to implement an event management methodfor a computer implemented business process system, the methodcomprising: providing a plurality of events for representing a businessprocess, the business process implemented by progressing through theevents; providing a plurality of event nodes for the business process,the event nodes defining points in a progress of the business processfor communicating with an external process to exchange information; andexecuting the business process by sequentially executing the events, theexecution proceeding in accordance with the event nodes.
 10. Thecomputer readable media of claim 9 wherein the step of providing aplurality of event nodes further includes providing a service noderepresenting the invocation of a business service.
 11. The computerreadable media of claim 9 wherein the step of providing a plurality ofevent nodes further includes providing a decision node specifying atleast one alternative or rule controlling an execution flow of theevents.
 12. The computer readable media of claim 9 wherein at least oneof the event nodes is a publish node for raising an event fornotification to the external process.
 13. The computer readable media ofclaim 9 wherein at least one of the event nodes is a request node forrequesting information from at least one of the plurality of events. 14.The computer readable media of claim 13 wherein the request node is ablocking node for blocking the execution of the business process untilthe requested information is provided.
 15. The computer readable mediaof claim 13 wherein the request node is a symbolic date request nodehaving a non-fixed calendar date of occurrence.
 16. The computerreadable media of claim 9 wherein the computer implemented businessprocess system is an XML (extensible markup language) based businessprocess system.
 17. A business process system for implementing eventmanagement for business process, comprising: a computer system having aprocessor for executing computer readable code; and a memory coupled tothe computer system storing computer readable code which when executedby the computer system cause the computer system to implement an eventmanagement method for a business process, the method comprising:providing a plurality of events for representing aspects of a businessprocess, the business process implemented by progressing through theevents; and providing a plurality of event nodes for the businessprocess, the event nodes defining points in a progress of the businessprocess for communicating with an external process to exchangeinformation.
 18. The system of claim 17 wherein events are grouped indifferent classes to simplify the specification of the events.
 19. Thesystem of claim 17 further including the step of defining at least oneof the events to include a symbolic date.
 20. The system of claim 17wherein at least one of the event nodes is a publish node for raising anevent for notification to the external process.
 21. The system of claim17 wherein at least one of the event nodes is a request node forrequesting information from at least one of the plurality of events orfor synchronizing execution with at least one of the plurality ofevents.
 22. The system of claim 21 wherein the request node is ablocking node for blocking the execution of the business process untilthe requested information is provided.
 23. The system of claim 21wherein the request node is a symbolic date request node having anon-fixed calendar date of occurrence.
 24. The system of claim 17wherein the event nodes are specified using an XML syntax.
 25. An eventmanagement system for business process management, comprising: means forexecuting a plurality of events for representing aspects of a businessprocess, the business process implemented by progressive executionthrough the events; and means for executing a plurality of event nodesfor the business process, the event nodes defining points in a progressof the business process for communicating with an external process toexchange information.
 26. The system of claim 25 wherein multiple eventtypes are grouped in different classes to structure the specification ofthe events.
 27. The system of claim 25 wherein at least one of theevents is defined to include a symbolic date.
 28. The system of claim 25wherein event for notification to the external process is implementedusing at least one publish node.
 29. The system of claim 25 wherein atleast one of the event nodes is a request node for requestinginformation from at least one of the plurality of events
 30. The systemof claim 25 wherein the request node is configured for synchronizingexecution with at least one of the plurality of events.
 31. The systemof claim 29 wherein the at least one request node is a blocking node forblocking the execution of the business process until the requestedinformation is provided.
 32. The system of claim 29 wherein the at leastone request node is a symbolic date request node having a non-fixedcalendar date of occurrence.
 33. The system of claim 25 wherein theevent nodes are specified using an XML syntax.
 34. A process monitoringand management method comprising: initializing an event monitorcomponent configured to monitor the occurrence of a plurality of eventsof a process; monitoring process execution as the plurality of eventsare sequentially executed, the monitoring performed by the event monitorcomponent; generate event parameters when a first event of the pluralityof events occurs and communicates information a second event; andnotifying the second event in accordance with the event parameters. 35.The method of claim 34 wherein the information communicated between thefirst event and the second event is conveyed via a message brokercomponent.
 36. The method of claim 35 wherein the plurality of eventsare configured to communicate with the message broker component via abroker interface component.
 37. The method of claim 36 wherein theplurality of events are configured to subscribe to the message brokercomponent to receive an event notification upon the occurrence of one ofthe plurality of events.
 38. The method of claim 36 wherein at least oneof the plurality of events is a state change event.
 39. The method ofclaim 36 wherein at least one of the plurality of events is an errorevent.
 40. The method of claim 36 wherein at least one of the pluralityof events is an application specific event.
 41. The method of claim 36wherein at least one of the plurality of events is a temporal event.